在 Day 3，我整理了自己第一次在 PawPal 團隊專案裡使用 Git 和 GitHub 的經驗。
當專案方向確定、協作流程也開始建立後，接下來就要真的進入開發。
而在這個過程中，對我影響很大的工具，就是 AI。
剛開始進入專案時，我其實還不知道 Codex 可以協助到什麼程度。
那時候我主要只會使用 ChatGPT，對 AI 輔助開發的理解也還很有限。
課程裡雖然有接觸到一些 AI 工具，但並沒有花非常大量的時間教我們怎麼使用 AI 開發。
所以很多用法，其實是我自己慢慢摸索出來的。
我會去找影片、看相關資訊，也會在實際開發過程中，一邊遇到問題，一邊嘗試怎麼問 AI。
這篇想整理的，不是 AI 有多厲害，也不是說 AI 幫我完成了整個專案。
我更想記錄的是：
身為一個前端新手，我是怎麼在 PawPal 專案裡使用 AI 協助自己開發，又是怎麼慢慢發現，AI 可以幫我更快找到方向，但不能替我真正理解專案。
剛開始使用 AI 時，我其實沒有什麼完整的方法。
比較像是遇到問題，就把問題丟給 AI。
看不懂錯誤訊息，就問 AI。
不知道功能怎麼拆，就問 AI。
程式碼看不懂，也問 AI。
甚至 Git、部署、PR、Issue、commit 訊息，只要我卡住，都會想問 AI。
那時候的 AI，對我來說比較像是一個救援工具。
因為我是新手，很多東西都還不熟。
有時候卡在一個問題上，如果完全靠自己查，可能會花非常久的時間。
AI 的確可以讓我比較快知道方向。
但我也不是完全沒有思考就直接問。
很多時候，我心裡會先有一個大概的想法，或是先猜這個問題可能跟哪裡有關。
只是我不確定自己的判斷對不對，所以會再去問 AI：
這樣想對嗎？
這個錯誤可能是什麼原因？
這個功能可以怎麼拆？
這段程式為什麼要這樣寫？
對當時的我來說，AI 很像是一個可以陪我確認方向的工具。
認真說起來，在 PawPal 專案裡，我幾乎從頭到尾都有使用 AI。
從一開始的專案規劃、功能拆解，到後面的程式撰寫、錯誤排查、Git 操作、部署問題，我都有問過 AI。
像是：
這些問題，AI 都曾經幫我提供過方向。
其中使用比例最高的，大概是兩件事：
第一個是產生程式碼。
第二個是解釋程式碼。
這兩件事對新手來說真的很重要。
因為剛開始寫專案時，我常常不是只有「不會寫」，而是連「為什麼要這樣寫」都還沒完全理解。
有時候 AI 給我一段範例，我可以先看出大概方向。
但真正重要的是後面那一步：
我要回頭問它，這一段在做什麼？
這個變數是什麼意思？
為什麼這裡要用這個方法？
如果我改掉這一段，會影響哪裡？
這些問題，才是幫助我理解的地方。
在專案前期，我很常直接把需求丟給 AI，請它幫我產生程式碼。
那時候我可能會描述：
我現在要做一個功能。
這個功能需要顯示某些資料。
使用者按下按鈕後，要送出資料。
資料要傳到後端。
畫面要更新。
然後 AI 會幫我產生一段範例。
那時候我會覺得很方便，因為原本自己可能不知道從哪裡開始，但 AI 可以先給我一個架構。
可是後來我也發現，只拿到程式碼是不夠的。
因為功能可以跑，不代表我真的理解。
所以除了請 AI 產生程式碼，我也很常請它解釋程式碼。
尤其是我看不懂的地方，我會一行一行問。
這一行在做什麼？
這個函式為什麼要這樣寫？
這裡的資料從哪裡來？
這個 API 回傳後，前端怎麼接？
有時候一段程式碼看起來很長，但如果 AI 可以幫我拆成一小段一小段說明，我就比較有機會慢慢理解。
所以對我來說，AI 最有幫助的地方，不只是給答案。
而是它可以把一個我原本看不懂的問題，拆成比較小的部分，讓我一步一步理解。
不過，AI 不是每次都能幫我解決問題。
我印象最深的一次，是部署。
對那時候的我來說，部署是一個很陌生的領域。
當時老師希望我們可以早點把專案部署起來，這樣後續測試和展示都會比較方便。
可是那時候我們主要開發的內容都還在 dev 分支。
main 分支幾乎沒有東西。
當時 Vercel 專案設定的 Production Branch 是 main，因此正式部署會以 main 的內容為準。
也就是說，明明我們主要開發的內容在 dev，線上網站卻沒有出現預期的更新。
那時候我就去問 AI。
我大概問了快一個小時。
我把遇到的情況描述給它，也照著它給的方向嘗試。
可是那一次，AI 其實沒有真的幫我解決問題。
最後是我自己在 Vercel 的專案設定裡慢慢找，才發現問題出在 Production Branch。將正式部署使用的分支調整後，網站才順利顯示開發中的內容。
這件事讓我印象很深。
因為它讓我發現，AI 不是萬能的。
它可以幫我提供方向，但如果我沒有提供完整的專案設定，它不一定能判斷真正的問題。
而且平台介面和設定位置可能更新，AI 提供的操作方式也不一定和我當下看到的畫面完全相同。
有些問題，還是要自己去找、自己點、自己測試。
那次部署事件讓我開始意識到：
AI 可以幫我節省時間，但它不能完全取代我對工具和專案的理解。
除了 AI 不一定能解決所有問題之外，我也踩過 AI 協作帶來的坑。
尤其是在專案前期，我比較不會下指令。
很多時候，我會直接把需求丟給 AI，請它幫我產生程式碼。
但問題是，如果我沒有把修改範圍講清楚，讓 AI 工具直接協助修改專案時，它可能會動到我沒有預期的檔案。
有幾次我發了 PR 之後，組員來問我：
為什麼你修改到我的檔案了？
我回頭檢查後才發現，AI 工具不只修改了原本功能相關的檔案，也動到其他組員負責的檔案。
這讓我很快意識到一件事：
AI 產出的東西不能直接相信。
尤其是在團隊專案裡，不是功能看起來可以跑就好。
還要確認它到底改了哪些檔案。
有沒有動到不該動的地方。
有沒有影響別人的功能。
PR 裡的修改範圍是不是乾淨。
如果沒有檢查，AI 幫我加快速度的同時，也可能幫我製造新的問題。
這也是我後來開始更小心使用 AI 的原因。
在 PawPal 專案裡，時間其實很有限。
我們需要在短時間內完成很多功能，也要處理畫面、API、資料庫、部署、測試和團隊協作。
所以老實說，很多時候我確實是靠 AI 協作來加快開發速度。
但做到中後期，我也開始思考：
這樣的做法到底對不對？
如果我太依賴 AI，會不會只是把功能做出來，但自己沒有真正理解？
如果我連自己的程式碼都沒有完全看懂，那我在 Code Review 時，又怎麼確定自己的修改沒有問題？
這種矛盾感其實蠻常出現的。
一方面，AI 真的幫我節省很多時間，也讓我在新手階段可以完成原本可能做不出來的功能。
但另一方面，我也知道，功能完成不代表我真的理解了。
程式碼可以跑，也不代表我能說明每一段在做什麼。
這也是我後來想挑戰鐵人賽的其中一個原因。
我想透過這 30 天，回頭整理那些當時靠 AI 協助完成的功能，重新理解它們背後的邏輯和觀念。
到專案後期，我開始慢慢調整使用 AI 的方式。
前期比較像是：
我提出需求，然後請 AI 直接產生程式碼。
但後期我開始改成：
先把需求講清楚。
再和 AI 討論這個功能應該怎麼驗證。
確認測試方向後，再請 AI 協助實作。
例如我會先想：
這個功能完成後，使用者應該可以做什麼？
畫面應該出現什麼結果？
送出資料後，資料有沒有正確更新？
重新整理後，資料還在不在？
手機版畫面會不會跑版？
這些其實比較像是人工測試的方向。
也就是說，我會自己打開網站，實際操作一次，確認功能是不是真的符合專案需求。
如果是新增功能，就真的新增一筆資料看看。
如果是編輯功能，就確認資料有沒有被更新。
如果是刪除功能，就確認畫面和資料狀態有沒有一致。
如果是手機版畫面，就切到不同尺寸檢查有沒有跑版。
測完之後，我還會回頭看程式碼。
不懂的地方，就一行一行問。
這樣的方式雖然比較慢，但我覺得比較踏實。
因為我不是只拿到 AI 幫我產生的結果，而是開始學著理解：
這段程式為什麼存在？
它有沒有符合需求？
如果出問題，我知道要從哪裡開始查嗎？
經過 PawPal 專案後，我對 AI 的看法變得比較清楚。
AI 對新手來說，真的很有幫助。
它可以幫助我理解陌生技術。
可以幫我分析錯誤訊息。
可以幫我整理需求。
可以提供不同的解決方向。
也可以在我不知道怎麼開始時，先給我一個參考架構。
但 AI 不是替代品。
它不能替我真正理解問題。
不能替我確認功能是不是符合需求。
也不能替我對整個專案負責。
所以我後來會提醒自己：
不要直接採用 AI 給的答案。
要自己測試。
要確認修改範圍。
要回頭理解程式碼。
真的不確定時，也要去查官方文件或找其他資料確認。
對我來說，AI 比較像是一個協助我學習和提升效率的工具。
它可以幫我更快找到方向。
但真正理解問題、驗證結果，以及完成作品，還是需要自己負責。
這一天回頭整理 AI 對我的幫助，我最大的感覺是：
AI 真的可以讓新手比較快進入開發狀態。
但如果只是把需求丟給 AI，然後直接照著用，其實很危險。
因為你可能不知道它改了什麼。
不知道它有沒有符合專案需求。
也不知道它是不是影響到其他人的功能。
在團隊專案裡，這些問題都會被放大。
所以 AI 最重要的用法，不是讓它取代我寫程式。
而是讓它幫我拆解問題、提供方向、解釋程式碼，最後再由我自己去驗證和理解。
AI 可以幫我走得比較快。
但要不要走對方向，還是要靠自己判斷。
今天，我整理了自己在 PawPal 專案中使用 AI 的方式。
從一開始把 AI 當成救援工具，到後來慢慢學會討論需求、確認測試方向、人工測試和理解程式碼，我也慢慢知道 AI 不能取代真正的理解。
下一篇，我想正式回到 PawPal 專案本身。
在開始打造第一個功能之前，我需要先認識整個專案的架構。
下一篇會聊聊：
認識 PawPal 的專案架構，準備開始打造第一個功能。
iThome鐵人賽
看影片追技術